\chapter{Framework Architecture}
\label{ch:Architecture}

In this chapter, we present the architecture of our proposed framework.

\begin{figure}[h]
    \centering
    \includegraphics[width=0.8\textwidth]{figures/general_arch}
    \caption{The general architecture of proposed framework}
    \label{fig:general_arch}
    %\vspace{-10pt}
\end{figure}

The general architecture of our proposed framework is illustrated in figure \ref{fig:general_arch}, which consists of following components:
\begin{itemize}
    \item \emph{Organizational Model Manager}: maintains the organizational descriptor model including the organizational model, evaluation model and event model.
    \item \emph{Organizational Model Editor} This component provides a GUI that allows users to edit the descriptor model in a graphical way.
    \item \emph{Solution Generator}: is in charge of generating a solution space. A solution is a goal-to-actor assignment scheme according to goals' decompositions and actors' capabilities. In this fashion, a solution is also called as configuration of the organizational model.
    \item \emph{Solution Simulation \& Assessment}: performs the vital task of the framework. This component takes each of solutions fed by Configuration generator, and carries out assortment. The output then is transferred to Assessment Visualization to support end-user to make decision on which solution shall be applied.
    \item \emph{Assessment Visualizer}: takes the simulation result and displays it in a user-friendly look such as charts, diagram, and so on.
\end{itemize}

\section{Organizational Model Manager and Editor}
\label{sec:OMM}

The \emph{Organizational Model Manager} (OMM) holds the information loaded from the \emph{organizational descriptor model} (ODM). This information is used to feed the \emph{Configuration Generator} and the \emph{Solution Assessment}. The OMM is also in charge of applying feedbacks to the organizational descriptor during assessment. All functions provided by the OMM can be easily accessed and reused the by the application. On the other hand, the OMM also provides an end-user interface to manipulate the ODM at runtime.

The ODM is the data model organizing data structure necessary for other parts of the framework. The ODM contains the information about the organizational model including list of goals, actors and dependency relationship between them. The ODM also maintains a list of registered evaluators and their configuration which is used to assess solutions for STS. Moreover, the ODM holds a description of the event model used by the the event-based simulator.

The detail of ODM will be discussed in chapter \ref{ch:ODM}.

\section{Solution Generator}
\label{sec:SolGenerator}

The \emph{Solution Generator} accesses the ODM managed in OMM and generates the solutions space which in turned used by the \emph{Solution Assessment}. From the \emph{potential organizational model}, the \emph{Solution Generator} tries to generate solutions by assigning goals to appropriate actors according to their capabilities. Since a goal can be provided by many actors, there are many ways to do the assignment. For example, if we have 3 goals and 3 actors which can provide each of these goals, then we have 3! = 6 possible combinations. The goal-to-actor assignment hence is a combinatorial problem which causes a terrible performance and computation issues if the number of goals and actors is just greater than 20.

Therefore, it is impossible to take one-by-one in the solution space and perform the evaluation to find which one is the best. The solution generator hence shows its important contribution to the success of the framework by filtering the solution space. Only considered-optimal solutions are fed to the \emph{Solution Assessment} for evaluation.

Instead of building the generator from scratch, we employ a general AI planner . The general AI planner takes an input describing the planning problem in the Problem Domain Definition Language (PDDL). The PDDL is an attempt to standardize planning domain and problem description languages. It was developed mainly to make the 1998/2000 International Planning Competitions possible. It was first developed by Drew McDermott in 1998 and later evolved with each International Planning Competitions. The latest version of this language is PDDL3.1

In the figure \ref{fig:solution_gen_arch}, it is the general architecture of the \emph{Solution Generator} component, which consists of four components:

\begin{itemize}
    \item \emph{PDDL Generator} extracts the \emph{potential organizational model} from the ODM and creates a corresponding PDDL problem file.
    \item \emph{Post PDDL processor} performs a late processing on the generated PDDL file. This component provides a mechanism to modify the PDDL file without affecting the ODM by maintaining a list of post-PDDL commands. A post-PDDL command is an introduction to add/remove a goal/fact from the generated PDDL script. Thank to this mechanism, the event simulator (later discussed in section \ref{sec:EventBasedSimulator}) can embed state of the world of the broken solution into the re-planning process.
    \item \emph{AI Planner} acts as a proxy between our framework and the external generic PDDL planner. The PDDL planner should be picked from the list of participants of the International Competition Planning\footnote{http://ipc.informatik.uni-freiburg.de/}.
    \item \emph{Solution Manager} collects and stored generated solutions for further assessment.
\end{itemize}

\begin{figure}
    \centering
    \includegraphics[width=0.7\textwidth]{figures/solution_gen_arch}
    \caption{General architecture of Solution Generator.}
    \label{fig:solution_gen_arch}
\end{figure}

\section{Solution Simulation, Assessment and Visualization}
\label{sec:SolAssessment}

This component takes a solution from the \emph{Solution Manager} to evaluate. The result then is displayed to end-user via a graphical ways such as tables, charts. There are two kinds of assessment considered in this framework: \emph{scalar quantitative assessment} and \emph{event-based quantitative assessment}. The quantitative assessment acts as a function of solution and returns a number representing the measurement of this solution. The returned measurement could be a set of numbers which explains how the final value is computed.

For example, consider Cost/Benefit evaluator which computes the benefit over cost quotient of a solution. This evaluator returns not only the quotient value, but also the values of benefit and cost.

The figure \ref{fig:simulation_arch} illustrates the architecture of the \emph{Solution Assessment} and \emph{Visualization}, including following sub components:
\begin{itemize}
    \item \emph{Solution Evaluator} acts as a front-end proxy that receives assessment request and forwards to appropriate scalar evaluator or the event-base simulator.
    \item \emph{Evaluator Registry} maintains a list of simple evaluators. Other components query the \emph{Evaluator Registry} for an instance of a specific evaluator to carry out assessment.
    \item \emph{Event Simulator} is in charge of simulating a solution in context of events. Given a solution with its corresponding ODM, the \emph{Event Simulator} passes this solution to the \emph{Solution Simulator}. For each time circle of the \emph{Solution Simulator}, the \emph{Event Simulator} checks the precondition of all active events in the Event Model of the ODM. If a precondition of an event is satisfied, this event is considered as happen and its post-conditions are executed.
    \item \emph{Solution Simulator} simulates the execution of a given solution. The \emph{Solution Simulator} is based on a time-based simulation algorithm (see algorithm \ref{algo:event-simul}) which executes solution's actions when their preconditions are matched.
    \item \emph{Visualizer} gets the evaluation result and renders it to end-users. The result will be displayed in a table if the assessment result is from a scalar evaluator. Otherwise, the \emph{Visualizer} will create a tree structure. The root will be the given solution, called solution node. When events happen while simulating this solution, a child node is created, called event node. If the solution is replanned, a special child node called branches is created, and for each new solution, it creates a child node for branches node. And the same logic is applied new solution nodes. The \emph{Visualizer} labels solution node with the measurement value of a selected scalar evaluator, event node with the time when this event happens. %The figure <NN> depicts an example of event-based assessment result.
\end{itemize}

\begin{figure}
    \centering
    \includegraphics[width=0.7\textwidth]{figures/simulation_arch}\\
    \caption{The architecture of the Solution Assessment and Visualization}
    \label{fig:simulation_arch}
\end{figure}
